YOW! Tech Leaders 2023

Date: 2023-09-07

#breakdown - convert these into individual zettels

Leading Technical Migrations - and How to Get Them to "Done" - Sarah Wells

No one gets excited about a migration project
Getting a migration right matters
Migrations are all about managing dependencies
- The less dependencies, the faster you can move. So remove any deps you can.
Timing is important
Understand what your goal is
It’s not a failure to cancel a migration
Clarity, Communication, Empathy
Clarity
- Why are you doing this?
- What is the finish line?
- Who needs to do work outside your own team?
- What context are they working in?
- What is the consequence of failing to hit the finish line?
Communication
- Be very very clear about: What exactly people need to do, When they need to do it by, What will happen if they don’t do it
- Use every channel you can
- Reach out to specific people directly
- Once you're sick of hearing the sound of your own voice, other people are just starting to hear you
Empathy
- Nudge theory
- EAST framework
  - Easy: Remove dependencies on you, visualise progress, do the work for them
  - Attractive: Make it clear what they and/or the organization get from this, give them something better
  - Social: Show them how they compare to others, encourage a public commitment
  - Timely: Pick the right time, help people make a plan, focus on immediate costs and benefits
Make sure you finish the migration
Two milestones in every migration:
- 1 - The old service is no longer used for new work
- 2 - The old service is no longer used at all
Define done at the start
Agree on an end date (it's okay for this to get postponed)

"A Technology Strategy is a plan to achieve long term organisational goals with technology."
Recommended reading: Good Strategy/Bad Strategy
Good Strategy: Consider all aspects of technology (people, technology, process). Balance practicality and inspirational. Are connected to the organisation and it's people
Earlier years of tech strategy must be clear and have timings, later years can be blurrier
Diagnosis should have 2-5 key challenges. This will omit some things but that's the point. Good for alignment.
Short document is better than a long document. Easier to share, but also helps clarify thinking and focus
Strategy needs be reviewed and updated regularly

Everyone has legacy, it's inevitable
Current dealing with legacy is poor: lack of respect, lack of ownership, poor best practices, poor team structures
Organisations are left with fragile systems that overall waste time due to lack of knowledge or care. Hard to make changes, hard to deal with incidents, 'impossible' to improve
Redefine legacy as 'heritage'. They have historical significance (and may still have some). While they're significant they should be appropriately maintained, but not necessarily changed.
Still moderate migrations and transformations away from legacy with keeping your legacy apps healthy
Remember legacy/heritage systems have to last the duration of the migration. You will spend time on them, willingly (improving the slate) or unwillingly (dealing with flake and incidents). Try to spend your time wisely
Heritage systems don't need to be as good as the 'new shiny stuff', but it also can't be entirely neglected.
Mindset from legacy to heritage has to come from the top

Remember you're dealing with people, not just 'resources'
Also keep in mind that there's advantages too, e.g. a global business footprint, timezone support, etc.
Culture is the main thing
Organisational culture - can change
National culture - can't change, learn to understand it
Hofstede Culture Insights Tool - helpful to compare national cultures

Staff engineer/IC track isn't just a way to increase salary
Staff engineers are force multipliers
Three types of staff engineers
- The connector
  - Binds teams and systems
  - Drive tech practices and migrations
- The domainer
  - Deep knowledge in important areas and domains
- The platformer
  - Deep knowledge in one tech area. Specialist, but scales.
All staff engineer types make everyone else's life easier
- Sharing knowledge, helping, coaching, etc
- Transparent, communicate well, build test, etc
- Good business sense
Staff engineering can go sideways too
- Connectors -> Bottlenecks
- Domainers -> Hoarders
- Platformers -> Thrill-seekers
- Set clear expectations and pathways to avoid this

Five principles on making tech decisions easier
1 - Decisions are made as close to the work as possible
2 - A leader's job is to bring info to the decision, not necessarily to make the decision. Context, principles, defaults, strategies
3 - Openly share decision making. Context, decisions, criteria, consequences.
- RFCs etc are good for this. A standard template: context, options, criteria, ranking, recommendation
4 - Seek dissent over approval. We're doing X, unless you really disagree or we've missed something
5 - Tie breakers are a last resort. Try not to pull rank unless you run out of time, have a 50/50 split, etc.

Keep the Fundamental Attribution Error in mind - we judge other's by their actions, and ourselves by our intentions. Other people do the same to you.
Don't create a gap between what you say and what you signal
- You are always on stage
- People talk about you as often as to you
Exceptions often create precedents
When you're sick of saying something, others are just starting to hear it
You will never get the benefit of the doubt
Learn other specialists' language
Attention is your most precious resource
- Don't deep dive on the things you know best or interest you most
Work on the things that only you can do
Naming creates things in people's mind. However, you can't un-name things
When someone makes a request for an 'obvious' decision, it's a trap
- If the decision is clear and obvious, the decision would have been made already
It's important to finish things. Keep your WIP low, and your options open

Data is a way to help you scale your leadership
1-on-1s don't scale
Get data at scale, then make decisions. Actionable data requires asking the right questions
Scalable input speeds up decision making and boost confidence
Code analysis/git is a great source of data
Chasing perfect data can stall decisions
80/20 rule is a powerful priority lever
Measure effectiveness so that you can ensure what you do is working, and is in the right direction
Data enables human judgement, it does not replace it.

Healthy conflict is not a negative
Healthy conflict often has:
- Aligned goals/outcomes
- Mutual respect/trust
- Positive intent
Health conflict: ideas win. Unhealthy conflict: people win
The perception of healthy vs unhealthy can differ per person
Name of the game is safe dialogue
If you can't make it healthy, take some time and distance, and try again later

No notes

Implement error budgets to improve operational excellence
If you exceed the error budget, you get 'punished'
Error budgets are informed by SLIs and SLOs
Dashboards should quickly surface problem areas, e.g. colours, grades, etc.
Provide visibility at different levels. Different people need different levels of scope